home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pem-mime-03.txt < prev    next >
Text File  |  1993-10-26  |  42KB  |  1,235 lines
  1.  
  2.           Network Working Group                            Steve Crocker
  3.           Internet Draft                                       Ned Freed
  4.           <draft-ietf-pem-mime-03.txt>                        Jim Galvin
  5.                                                             Sandy Murphy
  6.                                                            Marshall Rose
  7.  
  8.                                MIME-PEM Interaction
  9.  
  10.                                   Oct 15, 1993
  11.  
  12.  
  13.  
  14.  
  15.           1.  Status of this Memo
  16.  
  17.  
  18.           This document is an Internet Draft.  Internet Drafts are
  19.           working documents of the Internet Engineering Task Force
  20.           (IETF), its Areas, and its Working Groups.  Note that other
  21.           groups may also distribute working documents as Internet
  22.           Drafts.
  23.  
  24.  
  25.           Internet Drafts are valid for a maximum of six months and may
  26.           be updated, replaced, or obsoleted by other documents at any
  27.           time.  It is inappropriate to use Internet Drafts as reference
  28.           material or to cite them other than as a "work in progress".
  29.  
  30.  
  31.           2.  Abstract
  32.  
  33.           This memo defines a framework for interaction between MIME and
  34.           PEM services.  MIME, an acronym for "Multipurpose Internet
  35.           Mail Extensions", defines the format of the contents of
  36.           Internet mail messages and provides for multi-part textual and
  37.           non-textual message bodies.  PEM, an acronym for "Privacy
  38.           Enhanced Mail", provides message encryption and message
  39.           authentication/integrity services for Internet mail messages.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.           draft                MIME-PEM Interaction             Oct 1993
  60.  
  61.  
  62.           3.  Introduction
  63.  
  64.  
  65.           An Internet electronic mail message consists of two parts: the
  66.           headers and the body.  The headers form a collection of
  67.           field/value pairs structured according to RFC 822 [1], whilst
  68.           the body, if structured, is defined according to MIME [2].
  69.           MIME does not provide encryption or authentication/integrity
  70.           services.
  71.  
  72.  
  73.           PEM [3-6] allows encryption and authentication/integrity
  74.           enhancements to be applied to the contents of electronic mail
  75.           messages but does not provide message structuring or type
  76.           labelling facilities.
  77.  
  78.  
  79.           This memo defines a framework whereby the services provided by
  80.           MIME and PEM are used in a complementary fashion.  The 
  81.           resulting combined service provides encryption and 
  82.           authentication/integrity services for single-part and multi-
  83.           part textual and non-textual messages.  We refer to the 
  84.           authentication/integrity service as a signature.
  85.  
  86.  
  87.           The services of encryption and signature are separated. This 
  88.           differs from the service provided by [3], in that the 
  89.           encryption privacy enhancement in [3] also computes a 
  90.           signature of the message.  To take full advantage of the 
  91.           functionality provided by MIME, canonicalization and transfer 
  92.           encoding operations are removed from the privacy enhancement 
  93.           and left to the MIME agent.  The content domain header, 
  94.           defined in [3], is not included, as its functionality is 
  95.           subsumed by MIME. Transmission of certificate and certificate 
  96.           revocation lists is separated from the privacy enhancement.  
  97.           The message types no longer need be mentioned in the headers, 
  98.           as the information they impart is contained in the content 
  99.           types.  The requests and responses of [6] are provided for in 
  100.           new content types.
  101.  
  102.           This represents a departure in mechanism, although not in 
  103.           effect, from the procedures identified in [3].
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.           Expires Apr, 1994                                     [Page 2]
  112.  
  113.  
  114.  
  115.  
  116.  
  117.           draft                MIME-PEM Interaction             Oct 1993
  118.  
  119.  
  120.           MIME-PEM interaction is provided for by defining six new MIME   
  121.           content types: application/pem-keys, application/pem-
  122.           signature, application/pem-encrypted, application/quoted-mime-
  123.           entity, application/pem-request and application/certdata. The
  124.           MIME-PEM interaction also uses another new MIME type,
  125.           multipart/headerset, proposed by David Crocker.  The 
  126.           relationship between MIME and PEM is described in terms of two 
  127.           functions, message composition and message delivery.
  128.  
  129.  
  130.           The new content types have two different purposes.  The first
  131.           four types (application/pem-keys, application/pem-signature,
  132.           application/pem-encrypted and application/quoted-mime-entity)
  133.           are used to transmit and receive privacy enhanced messages and
  134.           are always encapsulated in a multipart/headerset body part.   
  135.           The last two types (application/pem-request and application/
  136.           certdata) are used to transmit requests for certificate
  137.           operations (retrieval, certification, revocation lists
  138.           retrieval, etc.) and the responses to those requests.  These
  139.           two content types are independent body parts, not required to
  140.           be encapsulated in any other body part.  The two groups of
  141.           content types are discussed in the two sections following.
  142.                                               
  143.  
  144.           4.  Definition of new enhancement Content Types
  145.  
  146.  
  147.           4.1.  Multipart/headerset Content Type Definition
  148.  
  149.  
  150.           (1)  MIME type name: multipart
  151.  
  152.           (2)  MIME subtype name: headerset
  153.  
  154.           (3)  Required parameters: boundary
  155.  
  156.           (4)  Optional parameters: none
  157.  
  158.           (5)  Encoding considerations: Either 7bit, 8bit, or binary
  159.                encoding may be used, depending on the nested part
  160.                encodings and transport limitations.
  161.  
  162.           (6)  Security Considerations: see [3]
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.           Expires Apr, 1994                                     [Page 3]
  171.  
  172.  
  173.  
  174.  
  175.  
  176.           draft                MIME-PEM Interaction             Oct 1993
  177.  
  178.  
  179.           The headerset subtype of multipart always contains at least      
  180.           two body parts, where the first body part gives instructions     
  181.           in some way for the processing of all the body parts.  In this   
  182.           use of the headerset subtype, there are always two body parts.   
  183.           The first part describes the privacy enhancement which was       
  184.           applied to the second body part. The first part's content type   
  185.           is application/pem-signature or application/pem-keys.            
  186.  
  187.  
  188.           The second body part contains a body part which contains the     
  189.           privacy-enhanced content.  The second part's content type is     
  190.           either application/pem-encrypted, if the requested privacy       
  191.           enhancement is encryption, or application/quoted-mime-entity,
  192.           if the requested privacy enhancement is signature.   
  193.  
  194.  
  195.           The syntax and semantics of the boundary parameter is defined
  196.           in [2].
  197.  
  198.  
  199.           4.2.  Application/pem-keys Content Type Definition               
  200.  
  201.           (1)  MIME type name: application
  202.  
  203.           (2)  MIME subtype name: pem-keys                                 
  204.  
  205.           (3)  Required parameters: none
  206.  
  207.           (4)  Optional parameters: none
  208.  
  209.           (5)  Encoding considerations: 7bit is always sufficient.
  210.  
  211.           (6)  Security Considerations: see [3]
  212.  
  213.  
  214.           The canonical form of this content type corresponds to the       
  215.           following production for <pemkeys>, which differs from the       
  216.           <pemhdr> in [3] in that neither the <crlhdr> nor the fields      
  217.           conveying certificates or related exclusively to signature are   
  218.           a part of the production.  (The certificate fields appear in
  219.           the application/certdata content type, see Section 5.2).  The
  220.           <contentdomain> field is also eliminated.  The <proctype>
  221.           field is replaced by the <version> field, as the message types
  222.           included in <proctype> are imparted by the content type name
  223.           of the body part.  The productions <dekinfo>, <origid-asymm>,
  224.  
  225.  
  226.  
  227.  
  228.  
  229.           Expires Apr, 1994                                     [Page 4]
  230.  
  231.  
  232.  
  233.  
  234.  
  235.           draft                MIME-PEM Interaction             Oct 1993
  236.  
  237.  
  238.           <origid-symm>, <recipflds> and <keyinfo> are as defined in
  239.           section 9 of [3].                 
  240.  
  241.  
  242.           <pemkeys> ::= <version>                                         
  243.                    <dekinfo>                                               
  244.                    (1*(<origkeyflds> *<recipflds>)) ; symmetric case       
  245.                    /((1*<origkeyflds>) *(<recipflds>)) ; asymmetric case 
  246.  
  247.           <version> ::= "Version" ":" "5" CRLF
  248.      
  249.           <origkeyflds> ::= <origid-asymm> [<keyinfo>]       ;asymmetric   
  250.                          / <origid-symm> [<keyinfo>]         ;symmetric    
  251.  
  252.  
  253.           This content type must be used as the first part of a            
  254.           multipart/headerset content type. It may not be used in any      
  255.           other context.                                                   
  256.  
  257.  
  258.           4.3.  Application/pem-signature Content Type Definition          
  259.  
  260.           (1)  MIME type name: application
  261.  
  262.           (2)  MIME subtype name: pem-signature                            
  263.  
  264.           (3)  Required parameters: none
  265.  
  266.           (4)  Optional parameters: none
  267.  
  268.           (5)  Encoding considerations: 7bit is always sufficient.
  269.  
  270.           (6)  Security Considerations: see [3]
  271.  
  272.  
  273.           The canonical form of this content type corresponds to the       
  274.           following production for <pemsig>, which differs from the        
  275.           <pemhdr> in [3] in that neither the <crlhdr> nor the fields      
  276.           conveying certificates or related exclusively to encryption      
  277.           are a part of the production.  (The certificate fields appear
  278.           in the application/certdata content type, see Section 5.2).
  279.           The <contentdomain> field is also eliminated.  The <proctype>
  280.           field is replaced by the <version> field, as the message types
  281.           included in <proctype> are imparted by the content type name
  282.           of the body part.  The productions <keyinfo>, <micinfo>,
  283.  
  284.  
  285.  
  286.  
  287.  
  288.           Expires Apr, 1994                                     [Page 5]
  289.  
  290.  
  291.  
  292.  
  293.  
  294.           draft                MIME-PEM Interaction             Oct 1993
  295.  
  296.  
  297.           <recipflds>, <origid-asymm> and <origid-symm> are as defined
  298.           in section 9 of [3].         
  299.  
  300.           <pemsig> ::= <version>                                          
  301.                    (1*(<origsigflds> *<recipflds>)) ; symmetric case       
  302.                    /((1*<origsigflds>) *(<recipflds>)) ; asymmetric case   
  303.  
  304.           <version> ::= "Version" ":" "5" CRLF
  305.  
  306.           <origsigflds> ::= <origid-asymm> [<keyinfo>]                     
  307.                          <micinfo>                           ;asymmetric   
  308.                          / <origid-symm> [<keyinfo>]         ;symmetric    
  309.  
  310.  
  311.           This content type must be used as the first part of a            
  312.           multipart/headerset content type. It may not be used in any      
  313.           other context.                                                   
  314.  
  315.  
  316.           4.4.  Application/pem-encrypted Content Type Definition
  317.  
  318.  
  319.           (1)  MIME type name: application
  320.  
  321.           (2)  MIME subtype name: pem-encrypted
  322.  
  323.           (3)  Required parameters: none
  324.  
  325.           (4)  Optional parameters: none
  326.  
  327.           (5)  Encoding considerations: The encryption will produce
  328.                binary data and may need to be encoded for transport.
  329.                Any transport-compatible encoding capable of  
  330.                accommodating binary data may be used.  A base64
  331.                encoding will be sufficient for all transport systems.
  332.                
  333.  
  334.           (6)  Security Considerations: see [3]
  335.  
  336.  
  337.           The content of the application/pem-encrypted is an encrypted     
  338.           valid MIME object.  Because it is encrypted, the canonical       
  339.           form of this content type is any arbitrary data.                 
  340.           This content type must be used as the second part of a           
  341.           multipart/headerset content type. It may not be used in any      
  342.  
  343.  
  344.  
  345.  
  346.  
  347.           Expires Jan, 1994                                     [Page 6]
  348.  
  349.  
  350.  
  351.  
  352.  
  353.           draft                MIME-PEM Interaction             Jul 1993
  354.  
  355.  
  356.           other context.
  357.  
  358.  
  359.           4.5.  Application/quoted-mime-entity Content Type Definition
  360.  
  361.  
  362.           (1)  MIME type name: application
  363.  
  364.           (2)  MIME subtype name: quoted-mime-entity
  365.  
  366.           (3)  Required parameters: none
  367.  
  368.           (4)  Optional parameters: none
  369.  
  370.           (5)  Encoding considerations: If the quoted 
  371.                mime body part has a quoted printable, 7bit, or base64
  372.                transfer encoding indicated, the transfer encoding
  373.                of this body part should be 7bit to avoid nested
  374.                encodings.  Otherwise, any transport-compatible
  375.                encoding capable of accommodating the content type of
  376.                the quoted mime body part may be used.
  377.  
  378.           (6)  Security Considerations: see [3]
  379.  
  380.  
  381.           The application/quoted-mime-entity content is constrained to 
  382.           be a valid MIME object.  The content of that body part must be 
  383.           in the canonical form for its content type. 
  384.  
  385.  
  386.           This content type must be used as the second part of a           
  387.           multipart/headerset content type. It may be used in any          
  388.           other context, as well.                                          
  389.  
  390.  
  391.           The application/quoted-mime-entity content type may on first 
  392.           inspection appear to be superfluous since the content it 
  393.           contains is itself constrained to be a valid MIME object.  
  394.           However, the use of application/quoted-mime-entity serves a 
  395.           vital function: it protects the inner MIME object from any 
  396.           changes that might be performed by messaging gateways. Such 
  397.           changes frequently disrupt header and boundary information,  
  398.           which in turn would lead to integrity check failures.
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.           Expires Apr, 1994                                     [Page 7]
  407.  
  408.  
  409.  
  410.  
  411.  
  412.           draft                MIME-PEM Interaction             Oct 1993
  413.  
  414.  
  415.           The use of application/quoted-mime-entity ensures that if a 
  416.           gateway is compelled to make encoding changes it will do so on
  417.           the application/quoted-mime-entity object as a whole. Such 
  418.           encoding changes, if done properly, will leave the
  419.           application/quoted-mime-entity content entirely intact.
  420.  
  421.  
  422.           The application/quoted-mime-entity type may be generally  
  423.           useful outside PEM, as well.  We intend for this to be a type 
  424.           that could be used anywhere in a MIME object and not  
  425.           restricted to PEM. 
  426.                                                
  427.  
  428.           5.  Definition of new certificate Content Types
  429.  
  430.  
  431.           5.1.  Application/pem-request Content Type Definition
  432.  
  433.           (1)  MIME type name: application
  434.  
  435.           (2)  MIME subtype name: pem-request
  436.  
  437.           (3)  Required parameters: none
  438.  
  439.           (4)  Optional parameters: none
  440.  
  441.           (5)  Encoding considerations: 7bit is always sufficient.
  442.  
  443.           (6)  Security Considerations: see [3]
  444.  
  445.  
  446.           The canonical form of this content type corresponds to the
  447.           following production.
  448.  
  449.           <request> ::= <version>
  450.           <version> ::= "Version" ":" "5" CRLF
  451.                         (<subject> / <issuer> / <certification>)
  452.           <subject> ::= "Subject" ":" <asymmid> CRLF
  453.           <issuer> ::= "Issuer" ":" <asymmid> CRLF
  454.           <certification> ::= "Certification" ":" <encbin> CRLF
  455.  
  456.  
  457.           The purpose of this body part is to transmit a request.  The
  458.           request can be "Certification", which requests certification
  459.           of a self-signed certificate, or "Subject", which requests the
  460.  
  461.  
  462.  
  463.  
  464.  
  465.           Expires Apr, 1994                                     [Page 8]
  466.  
  467.  
  468.  
  469.  
  470.  
  471.           draft                MIME-PEM Interaction             Oct 1993
  472.  
  473.  
  474.           certificate chain corresponding to a subject identified by a 
  475.           distinguished name, or "Issuer", which requests the revocation 
  476.           list chain issued by an issuer identified by a distinguished
  477.           name. The "Subject" and "Issuer" fields each contain a value
  478.           of type Name, encoded according to the Basic Encoding Rules,
  479.           then in ASCII, as for the "Originator-ID-Asymmetric" field of
  480.           [3].
  481.  
  482.  
  483.           In each case, the response can be transmitted in an
  484.           application/certdata content type.
  485.  
  486.  
  487.           This type is intended to provide for the requests described
  488.           in [6].  The key certification request and CRL-retrieval
  489.           request are provided for directly.  The CRL-storage request
  490.           is provided for by transmitting the CRL's to be stored in an
  491.           application/certdata content type. 
  492.  
  493.  
  494.           5.2.  Application/certdata Content Type Definition
  495.  
  496.           (1)  MIME type name: application
  497.  
  498.           (2)  MIME subtype name: certdata
  499.  
  500.           (3)  Required parameters: none
  501.  
  502.           (4)  Optional parameters: none
  503.  
  504.           (5)  Encoding considerations: 7bit is always sufficient.
  505.  
  506.           (6)  Security Considerations: see [3]
  507.  
  508.  
  509.           The canonical form of this content type corresponds to the
  510.           following production built on top of the definitions in
  511.           section 9 of [3].                                                
  512.  
  513.           <certdata> ::= <certchain> / <crlchain>                          
  514.           <certchain> ::= <version> (<cert> *([<crl>]<cert>))
  515.           <crlchain> ::= <version> 1*(<crl>[<cert])                 
  516.           <cert> ::= "Certificate" ":" <encbin> CRLF                  
  517.           <version> ::= "Version" ":" "5" CRLF
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.           Expires Apr, 1994                                     [Page 9]
  525.  
  526.  
  527.  
  528.  
  529.  
  530.           draft                MIME-PEM Interaction             Oct 1993
  531.  
  532.  
  533.  
  534.           This content type is used to transfer certificate or             
  535.           certificate revocation list information.  This information is    
  536.           entirely independent of any particular enhanced message. (Note
  537.           that the converse is not true: the validity of an enhanced
  538.           message cannot be determined without the proper certificates     
  539.           or current CRL information.)  As such, the application/pem-      
  540.           certdata content type is an independent body part.  It is not     
  541.           used in a multipart/headerset context containing PEM enhanced    
  542.           messages.                                                        
  543.  
  544.  
  545.           The <certchain> production contains one certificate chain.   
  546.           Each certificate chain starts with a certificate and continues 
  547.           with the certificates of subsequent issuers.  Each issuer  
  548.           listed is presumed to have issued the preceding certificate.   
  549.           For each issuer, a CRL may be supplied.  A CRL in the chain  
  550.           belongs to the immediately following issuer. Therefore, it  
  551.           potentially contains the immediately preceding certificate.
  552.  
  553.  
  554.  
  555.           The <crlchain> production contains one certificate revocation    
  556.           list chain.  The CRLs in the chain begin with a requested CRL    
  557.           and continue with the CRLs of subsequent issuers.  The issuer    
  558.           of each CRL is presumed to have issued a certificate for the     
  559.           issuer of the preceding CRL.  For each CRL, the issuer's         
  560.           certificate may be supplied.  A certificate in the chain must      
  561.           belong to the issuer of the immediately preceding CRL.
  562.  
  563.  
  564.           The relationship between a certificate and an immediately        
  565.           preceding CRL is the same in both cases.  In a <certchain>       
  566.           the crl's are optional.  In a <crlchain>, the certificates       
  567.           are optional.                                                          
  568.  
  569.  
  570.           6.  Message Composition
  571.  
  572.  
  573.           When a user composes a message, it is the responsibility of
  574.           the user agent to construct a valid MIME message.  In
  575.           particular, Content-Type: and Content-Transfer-Encoding:
  576.           headers should be used wherever they are appropriate.  This
  577.           allows the receiving user agent to unambiguously interpret the
  578.  
  579.  
  580.  
  581.  
  582.  
  583.           Expires Apr, 1994                                    [Page 10]
  584.  
  585.  
  586.  
  587.  
  588.  
  589.           draft                MIME-PEM Interaction             Oct 1993
  590.  
  591.  
  592.           message body and process it accordingly.
  593.  
  594.  
  595.           Each block of content headers associated with either an RFC822
  596.           <message> or with a MIME <body-part> represents a logical
  597.           place where privacy enhancement can be requested.  A privacy
  598.           enhancement request associated with a particular <message> or
  599.           <body-part> content is taken to apply to the entire content;
  600.           it is not possible to privacy-enhance only a portion of a body
  601.           part.
  602.  
  603.  
  604.           The mechanism used to communicate privacy enhancement requests
  605.           to the pre-submission processor described below is strictly a
  606.           local implementation issue. However, the interface between the
  607.           message composer and pre-submission processing MUST be
  608.           trustworthy, since the message composer relies on pre-
  609.           submission processing to either perform the requested privacy
  610.           enhancement operation or return an error.  Regardless of the
  611.           mechanism chosen, great care should be taken to safeguard
  612.           against both the release of information that has not received
  613.           the requested type of privacy enhancement as well as tampering
  614.           with the enhancement request itself.
  615.  
  616.  
  617.           6.1.  Pre-Submission Algorithm
  618.  
  619.  
  620.           The user agent first composes a MIME-compliant message and
  621.           then applies this algorithm:
  622.  
  623.  
  624.           (1)  If the content at this (initially top) level has NOT been
  625.                selected for privacy enhancement, the user agent sees if
  626.                the content is either multipart or message.  If so, it
  627.                then recursively applies this algorithm to the
  628.                encapsulated body parts; if not, it terminates processing
  629.                for this content.
  630.  
  631.           (2)  If the content at this level has been selected for  
  632.                privacy enhancement, then the content, including its
  633.                headers, constitutes the object that receives privacy
  634.                enhancement.  The headers at a minimum will include a
  635.                Content-Type header, either explicit or implicit.  The
  636.                object will eventually be replaced with the multipart/
  637.  
  638.  
  639.  
  640.  
  641.  
  642.           Expires Apr, 1994                                    [Page 11]
  643.  
  644.  
  645.  
  646.  
  647.  
  648.           draft                MIME-PEM Interaction             Oct 1993
  649.  
  650.  
  651.                headerset content that is produced by the privacy
  652.                enhancement operation.              
  653.  
  654.           (3)  The content of the object must be transformed from local
  655.                form to its MIME binary canonical form.  Also, if the 
  656.                requested privacy enhancement is signature, and if
  657.                Content-Transfer-Encoding: headers were present in the
  658.                headers of the object, the content encoding is reversed,
  659.                leaving only 7BIT, 8BIT, and BINARY as possible encodings
  660.                for all body parts.  This is done so that any artifacts
  661.                introduced by encoding are removed and consistent
  662.                integrity checks will be generated.
  663.  
  664.           (4)  Once an object in binary canonical form has been produced
  665.                the selected privacy enhancement is performed.  The 
  666.                privacy enhancement produces two data streams: the 
  667.                privacy enhanced object and a control stream comprised
  668.                of a set of headers as defined in the <pemsig> or
  669.                <pemkeys> productions.
  670.  
  671.           (5)  A new body part is then constructed, of content type
  672.                multipart/headerset.  The body part contains two
  673.                body parts, whose content depends on the privacy
  674.                enhancement requested.
  675.  
  676.                (a) If the requested privacy enhancement is encryption,
  677.                    then the first body part within the multipart/
  678.                    headerset is labelled with a content type of
  679.                    application/pem-keys and contains the <pemkeys> 
  680.                    control stream produced by the privacy enhancement.
  681.                    The second body part within the multipart/headerset 
  682.                    is labelled with a content type application/pem-
  683.                    encrypted, and contains the privacy enhanced object 
  684.                    produced by the privacy enhancement.  An appropriate 
  685.                    transfer encoding is also applied to the content and 
  686.                    a corresponding Content-Transfer-Encoding: header is 
  687.                    added to the application/pem-encrypted body part.
  688.                    Base64 encoding is recommended in the case of
  689.                    encryption privacy enhancement in order to be
  690.                    backwards-compatible with the original PEM
  691.                    conventions.
  692.  
  693.                (b) If the requested privacy enhancement is signature, 
  694.                    then the first body part within the multipart/
  695.                    headerset is labelled with a content type of 
  696.  
  697.  
  698.  
  699.  
  700.  
  701.           Expires Apr, 1994                                    [Page 12]
  702.  
  703.  
  704.  
  705.  
  706.  
  707.           draft                MIME-PEM Interaction             Oct 1993
  708.  
  709.  
  710.                    application/pem-signature and contains the <pemsig> 
  711.                    control stream produced by the privacy enhancement.  
  712.                    The second body part within the multipart/headerset 
  713.                    is labelled with a content type application/quoted-
  714.                    mime-entity, and contains the privacy enhanced object 
  715.                    produced by the privacy enhancement.  An appropriate 
  716.                    transfer encoding is also applied to the content and 
  717.                    a corresponding Content-Transfer-Encoding: header is 
  718.                    added to the application/quoted-mime-entity bodypart.
  719.         
  720.                This multipart/headerset content replaces the original
  721.                object.
  722.  
  723.  
  724.           7.  Post-Delivery Algorithm
  725.  
  726.           When a user receives a message containing a multipart/
  727.           headerset content, the user agent may transform the content
  728.           back into its original form prior to privacy-enhancement.
  729.           This operation, the post-delivery algorithm, is performed by
  730.           reversing the steps performed during the pre-submission
  731.           algorithm.
  732.  
  733.           When the original content is reconstituted into its MIME
  734.           binary canonical form, it may use octet values outside of the
  735.           US-ASCII repertoire and may contain body parts without line
  736.           breaks.  If the user agent replaces the multipart/headerset
  737.           content with the original content, then it must select
  738.           appropriate Content-Transfer-Encodings for each body part and
  739.           add corresponding Content-Transfer-Encoding: headers.
  740.  
  741.           Upon successful completion of the post-delivery algorithm for
  742.           each content, the type of privacy enhancement that was in
  743.           effect for that content must be communicated to the user.  The
  744.           mechanism used to do this is a local implementation issue. As
  745.           with requests for privacy enhancement to the pre-submission
  746.           algorithm, the path between post-delivery processing and
  747.           actual display of the message must be a trusted one, lest a
  748.           message be presented that purports to have undergone some form
  749.           of privacy enhancement it did not in fact receive.
  750.  
  751.  
  752.           8.  Examples
  753.  
  754.           For example, suppose the following body part was selected for
  755.  
  756.  
  757.  
  758.  
  759.  
  760.           Expires Apr, 1994                                    [Page 13]
  761.  
  762.  
  763.  
  764.  
  765.  
  766.           draft                MIME-PEM Interaction             Oct 1993
  767.  
  768.  
  769.           privacy enhancement:
  770.  
  771.  
  772.                Content-Type: message/rfc822
  773.  
  774.                To: ned@innosoft.com
  775.                Subject: example #1
  776.                MIME-Version: 1.0
  777.                Content-Type: text/plain; charset=us-ascii
  778.  
  779.                Hi Ned.  See how much nicer this works!
  780.  
  781.  
  782.           After applying pre-submission algorithm with a request that
  783.           signature privacy enhancement be applied to the body part, the 
  784.           body part submitted for delivery would appear as:
  785.  
  786.  
  787.                Content-Type: multipart/headerset;
  788.                              boundary="Privacy Boundary"
  789.  
  790.                --Privacy Boundary
  791.                Content-Type: application/pem-signature
  792.  
  793.                Version: 5
  794.                Originator-ID-Asymmetric: ...,09
  795.                MIC-Info: RSA-MD5,RSA,...
  796.  
  797.                --Privacy Boundary
  798.                Content-Type: application/quoted-mime-entity
  799.  
  800.                Content-Type: message/rfc822
  801.  
  802.                To: ned@innosoft.com
  803.                Subject: example #1
  804.                MIME-Version: 1.0
  805.                Content-Type: text/plain; charset=us-ascii
  806.  
  807.                Hi Ned.  See how much nicer this works!
  808.  
  809.                --Privacy Boundary--
  810.  
  811.  
  812.           After applying the post-delivery algorithm, the resulting
  813.           body part would once again appear as:
  814.  
  815.  
  816.  
  817.  
  818.  
  819.           Expires Apr, 1994                                    [Page 14]
  820.  
  821.  
  822.  
  823.  
  824.  
  825.           draft                MIME-PEM Interaction             Oct 1993
  826.  
  827.  
  828.  
  829.                Content-Type: message/rfc822
  830.  
  831.                To: ned@innosoft.com
  832.                Subject: example #1
  833.                MIME-Version: 1.0
  834.                Content-Type: text/plain; charset=us-ascii
  835.  
  836.                Hi Ned.  See how much nicer this works!
  837.  
  838.  
  839.           The body part need not be ascii text.  For example, the
  840.           following audio body part could be privacy enhanced:
  841.  
  842.                Content-Type: audio
  843.                Content-Transfer-Encoding: base64
  844.  
  845.                JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
  846.                GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
  847.                kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj
  848.  
  849.           producing the following body part:
  850.  
  851.  
  852.                Content-Type: multipart/headerset;
  853.                              boundary="Privacy Boundary"
  854.  
  855.                --Privacy Boundary
  856.                Content-Type: application/pem-signature
  857.  
  858.                Version: 5
  859.                Originator-ID-Asymmetric: ...,09
  860.                MIC-Info: RSA-MD5,RSA,...
  861.  
  862.                --Privacy Boundary
  863.                Content-Type: application/quoted-mime-entity
  864.                Content-Transfer-Encoding: 7bit
  865.  
  866.                Content-Type: audio
  867.                Content-Transfer-Encoding: base64
  868.  
  869.                JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
  870.                GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
  871.                kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.           Expires Apr, 1994                                    [Page 15]
  879.  
  880.  
  881.  
  882.  
  883.  
  884.           draft                MIME-PEM Interaction             Jul 1993
  885.  
  886.  
  887.                --Privacy Boundary--
  888.  
  889.  
  890.  
  891.  
  892.           The following privacy-enhanced message illustrates how an
  893.           enhanced body part can itself receive enhancement.
  894.  
  895.                Date:    Mon, 29 Mar 93 13:57:08 -0500
  896.                From:    Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
  897.                To:      Marshall Rose <mrose@dbc.mtview.ca.us>
  898.                Subject: Forwarded integrity Message
  899.                MIME-Version: 1.0
  900.                Content-Type: multipart/headerset;
  901.                              boundary="Privacy Boundary"
  902.  
  903.                --Privacy Boundary
  904.                Content-Type: application/pem-signature
  905.  
  906.                Version: 5
  907.                Originator-ID-Asymmetric: ...,09
  908.                MIC-Info: RSA-MD5,RSA,...
  909.  
  910.                --Privacy Boundary
  911.                Content-Type: application/quoted-mime-entity
  912.  
  913.                Content-Type: multipart/mixed;
  914.                              boundary="Middle Boundary"
  915.  
  916.                --Middle boundary
  917.                Content-Type: text/plain; charset=us-ascii
  918.  
  919.                The enclosed message was integrity enhanced.
  920.  
  921.                Greg V.
  922.  
  923.                --Middle Boundary
  924.                Content-Type: multipart/headerset;
  925.                              boundary="Forwarded Message"
  926.  
  927.                --Forwarded Message
  928.                Content-Type: application/pem-signature
  929.  
  930.                Version: 5
  931.                Originator-ID-Asymmetric: ...,09
  932.  
  933.  
  934.  
  935.  
  936.  
  937.           Expires Apr, 1994                                    [Page 16]
  938.  
  939.  
  940.  
  941.  
  942.  
  943.           draft                MIME-PEM Interaction             Jul 1993
  944.  
  945.  
  946.                MIC-Info: RSA-MD5,RSA,...
  947.  
  948.                --Forwarded Message
  949.                Content-Type: application/quoted-mime-entity
  950.  
  951.                Content-Type: message/RFC822
  952.  
  953.                Date:    Mon, 29 Mar 93 13:53:02 -0500
  954.                From:    Ned Freed <ned@innosoft.com>
  955.                To:      Greg Vaudreuil <gvaudre@IETF.CNRI.Reston.VA.US>
  956.                Subject: Minimal PEM Message
  957.  
  958.                This is a signed message using MIME-PEM.
  959.  
  960.                Greg V.
  961.  
  962.                --Forwarded Message--
  963.  
  964.                --Middle Boundary--
  965.  
  966.                --Privacy Boundary--
  967.  
  968.  
  969.           The following privacy-enhanced body part illustrates the use
  970.           of encryption and the application/pem-encrypted content type.
  971.  
  972.                Content-Type: multipart/headerset;
  973.                              boundary="PEM Boundary"
  974.  
  975.                --PEM Boundary
  976.                Content-Type: application/pem-keys
  977.  
  978.                Version: 5
  979.                DEK-Info: DES-CBC,4C776432D61A9829
  980.                Originator-ID-Asymmetric: ...,09
  981.                Key-Info: RSA,...
  982.  
  983.                --PEM Boundary
  984.                Content-Type: application/pem-encrypted
  985.                Content-Transfer-Encoding: base64
  986.  
  987.                8R/EVhZy7OU= 
  988.  
  989.                --PEM Boundary--
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.           Expires Apr, 1994                                    [Page 17]
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.           draft                MIME-PEM Interaction             Jul 1993
  1003.  
  1004.  
  1005.  
  1006.  
  1007.           If it was desired to produce a signed and encrypted body part,     
  1008.           the signature would be done first, producing:                    
  1009.  
  1010.  
  1011.                Content-Type: multipart/headerset;
  1012.                              boundary="Sign Boundary" 
  1013.  
  1014.                --Sign Boundary                                             
  1015.                Content-Type: application/pem-signature                     
  1016.  
  1017.                Version: 5                                       
  1018.                Originator-ID-Asymmetric: ...,09                            
  1019.                MIC-Info: RSA-MD5,RSA,...                                   
  1020.  
  1021.                --Sign Boundary                                             
  1022.                Content-Type: application/quoted-mime-entity
  1023.  
  1024.                Content-Type: message/RFC822                                
  1025.  
  1026.                To:    Ned Freed <ned@innosoft.com>                         
  1027.                Subject: Strongly Protected Message                         
  1028.  
  1029.                This will be signed and encrypted.  Let the bad guys        
  1030.                do their worst!                                             
  1031.  
  1032.                Jim                                                         
  1033.  
  1034.                --Sign Boundary--                                           
  1035.  
  1036.           and then it would be encrypted, producing:                       
  1037.  
  1038.                Content-Type: multipart/headerset;
  1039.                              boundary="Enc Boundary"  
  1040.  
  1041.                --Enc Boundary
  1042.                Content-Type: application/pem-keys                          
  1043.  
  1044.                Version: 5                                      
  1045.                DEK-Info: DES-CBC,4C776432D61A9829                          
  1046.                Originator-ID-Asymmetric: ...,09                            
  1047.                Key-Info: RSA,...                                           
  1048.  
  1049.                --Enc Boundary                                              
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.           Expires Apr, 1994                                    [Page 18]
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.           draft                MIME-PEM Interaction             Jul 1993
  1062.  
  1063.  
  1064.                Content-Type: application/pem-encrypted                     
  1065.                Content-Transfer-Encoding: base64                           
  1066.  
  1067.                9S/FWjAz8P=V                                                
  1068.  
  1069.                --Enc Boundary--                                            
  1070.  
  1071.  
  1072.           where the encrypted contents, 9S/FWjAz8P=V, are the encryption   
  1073.           of the first multipart/headerset.                                
  1074.  
  1075.  
  1076.           9.  Observations
  1077.  
  1078.           The use of the pre-submission and post-delivery algorithms to
  1079.           combine PEM and MIME capabilities exhibit several properties:
  1080.  
  1081.           (1)  It allows privacy-enhancement of an arbitrary content,
  1082.                not just an entire RFC 822 message.
  1083.  
  1084.           (2)  For a multipart or message content, it allows the user to
  1085.                decide whether the structure of the content should
  1086.                receive what sort of privacy-enhancement.
  1087.  
  1088.           (3)  It provides for messages containing several privacy
  1089.                enhanced contents, thereby removing the requirement for
  1090.                PEM software to be able to generate or interpret a single
  1091.                content which intermixes both unenhanced and enhanced
  1092.                components.
  1093.  
  1094.  
  1095.       The use of a MIME-capable user agent makes complex nesting of    
  1096.       enhanced message body parts much easier.  For example, the     
  1097.       user can separately sign and encrypt a message.  This     
  1098.       motivates a complete separation of the confidentiality     
  1099.       security service from the authentication/message integrity     
  1100.       security service.  That is, different keys could be used for     
  1101.       the different services and protected separately.  In the     
  1102.       asymmetric case, this means an employee's company could be     
  1103.       given access to the (private) decryption key, granting the     
  1104.       company the ability to decrypt messages addressed to the     
  1105.       employee in emergencies, without also granting the company     
  1106.       the ability to sign messages as the employee.                        
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.           Expires Apr, 1994                                    [Page 19]
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.           draft                MIME-PEM Interaction             Jul 1993
  1121.  
  1122.  
  1123.           The use of two private keys requires the ability to maintain     
  1124.           multiple certificates for each user.                             
  1125.  
  1126.  
  1127.           10.  Acknowledgements
  1128.  
  1129.           David H. Crocker suggested the use of a multipart structure
  1130.           for MIME-PEM interaction.
  1131.  
  1132.  
  1133.           11.  References
  1134.  
  1135.           [1]  D.H. Crocker, Standard for the Format of ARPA Internet
  1136.                Text Messages, RFC 822, August, 1982.
  1137.  
  1138.           [2]  N. Borenstein, N. Freed, Multipurpose Internet Mail
  1139.                Extensions, RFC 1341, June 1992.
  1140.  
  1141.           [3]  J. Linn, Privacy Enhancement for Internet Electronic
  1142.                Mail -- Part I: Message Encryption and Authentication
  1143.                Procedures, RFC 1421, DEC, February 1993.
  1144.  
  1145.           [4]  S. Kent, Privacy Enhancement for Internet Electronic
  1146.                Mail -- Part II: Certificate-Based Key Management, RFC
  1147.                1422, BBN, February 1993.
  1148.  
  1149.           [5]  D. Balenson, Privacy Enhancement for Internet Electronic
  1150.                Mail -- Part III: Algorithms, Modes, and Identifiers, RFC
  1151.                1423, TIS, February 1993.
  1152.  
  1153.           [6]  B. Kaliski, Privacy Enhancement for Internet Electronic
  1154.                Mail -- Part IV: Key Certification and Related Services,
  1155.                RFC 1424, RSA Laboratories, February 1993.
  1156.  
  1157.           [7]  R. Braden, Editor, Requirements for Internet Hosts --
  1158.                 Application and Support, RFC 1123, October 1989.
  1159.  
  1160.  
  1161.           12.  Author Addresses
  1162.  
  1163.           Steve Crocker
  1164.           Trusted Information Systems
  1165.           3060 Washington Road
  1166.           Glenwood, MD  21738
  1167.           email:  crocker@tis.com
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.           Expires Apr, 1994                                    [Page 20]
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.           draft                MIME-PEM Interaction             Jul 1993
  1180.  
  1181.  
  1182.  
  1183.           Ned Freed
  1184.           Innosoft International, Inc.
  1185.           250 West First Street, Suite 240
  1186.           Claremont, CA 91711
  1187.           USA
  1188.           Tel:    +1 909 624 7907
  1189.           Fax:    +1 909 621 5319
  1190.           email:  ned@innosoft.com
  1191.  
  1192.  
  1193.           Jim Galvin
  1194.           Trusted Information Systems
  1195.           3060 Washington Road
  1196.           Glenwood, MD  21738
  1197.           email:  galvin@tis.com
  1198.  
  1199.           Sandra Murphy
  1200.           Trusted Information Systems
  1201.           3060 Washington Road
  1202.           Glenwood, MD  21738
  1203.           email:  murphy@tis.com
  1204.  
  1205.           Marshall T. Rose
  1206.           Dover Beach Consulting, Inc.
  1207.           420 Whisman Court
  1208.           Mountain View, CA  94043-2186
  1209.           Tel:    +1 415 968 1052
  1210.           Fax:    +1 415 968 2510
  1211.           email:  mrose@dbc.mtview.ca.us
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.           Expires Apr, 1994                                    [Page 21]
  1233.  
  1234.  
  1235.